home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group95a.txt / 000049_icon-group-sender _Sun Feb 5 11:51:09 1995.msg < prev    next >
Internet Message Format  |  1995-02-09  |  5KB
  1. Received: by cheltenham.cs.arizona.edu; Sun, 5 Feb 1995 10:48:23 MST
  2. Date: Sun, 5 Feb 95 11:51:09 CST
  3. From: goer@mithra-orinst.uchicago.edu (Richard L. Goerwitz)
  4. Message-Id: <9502051751.AA10095@mithra-orinst.uchicago.edu>
  5. To: icon-group@cs.arizona.edu
  6. Subject: sockets, loadfunc, etc.
  7. Errors-To: icon-group-errors@cs.arizona.edu
  8.  
  9. Sometimes I wish I could live two different lives - one as a CS
  10. groupie, and another in my own field.  Sigh.
  11.  
  12. As far as loadfunc goes, my observation was - when I first saw
  13. it - that its arguments were in reverse order.  Library first,
  14. then function.  The problem is that, in order to fully load a
  15. function, and resolve all references external to the function
  16. (including global variables) often requires iterative loads of
  17. multiple libraries and functions.  The GNU DLD system, as I re-
  18. call, does things this way.  So, as far as loadfunc is concern-
  19. ed, this means that it should take a function as its first arg,
  20. then a variable-length list of libraries.
  21.  
  22. Loadfunc, as it stands now, also appears to lean heavily on fea-
  23. tures specific to just a few Unix platforms.
  24.  
  25. Things may have changed, and I may not be understanding properly.
  26. This ain't my area, as I noted above.  And certainly no one ex-
  27. pects people like you, Clint, or Ralph, Gregg, etc., to cater to
  28. every feature request.  I really wish I had thetbasic ability
  29. just to roll up my sleeves and work on the implementation myself,
  30. but I don't any more.
  31.  
  32. I guess the deeper question with loadfunc, sockets, and every-
  33. thing else like this, is not so much how one extends Icon to be
  34. all things to all people.  The question is how to provide a
  35. simple, elegant, portable method of hooking Icon into platform-
  36. specific utilities, libraries, and OS features.  We obviously
  37. can't exect sockets under DOS or many other such (minimal) op-
  38. erating systems.  And there's really no point in extending Icon
  39. just for Unix.  Yet loadfunc, as far as I know, is also very
  40. platform-specific (relying, as noted, on what I believe to be
  41. a not-widely-implemented feature of certain commercial Unix
  42. systems), so even under Unix it's not possible to offer sockets
  43. via an external interface.  Either way, that is, we are stuck
  44. (having either to design a large new module for the run-time
  45. system, or use a platform-specific loadfunc tool).
  46.  
  47. The same problem, of course, comes up with wider modules like
  48. the windowing system.  Sure, it's great to have a windowing sys-
  49. tem that works with a number of different platforms.  But this
  50. places a heavy, heavy implementation burden on the Icon Project.
  51. One that has not yet been met.  In a way, I wonder how it *can*
  52. be met.  You are human, after all.  Yet I know that I personally
  53. could no longer tack on an interface between, say, Icon and
  54. Motif or a curses library (though I did create an interface to
  55. the curses functions for 8.0, it was primitive, and I was never
  56. happy with the way it went into Icon).
  57.  
  58. And, just to continue this line of thought a moment, I wonder
  59. what happens as changes occur in areas like internationalization.
  60. Motif 2.0 is becoming multilingual.  You can now display mixed-
  61. language text.  On the Mac there is WorldScript.  Under NT there
  62. is some primitive Unicode support.  It is crazy to think that
  63. a few Icon programmers can duplicate all of this functionality.
  64. Or that they would even want to.  It's like doing sockets.  The
  65. goal should be to provide a generalized method of interfacing
  66. Icon with platform-specific features and tools, without placing
  67. the burden of implementation entirely on guys like you.
  68.  
  69. I don't want to imply, BTW, that graphics are bad.  This idea
  70. was and is really neat.  But ultimately I think what we really
  71. want is a pretty lean core Icon run-time system.  I fear with
  72. all the complexity of 9.0 and graphics that implementation will
  73. become so difficult that development will essentially stall.
  74. Worse yet, it will become well nigh impossible to find volun-
  75. teers to work on Icon.  I actually used to be able to do that
  76. myself.  Clint, you and Gregg probably remember with some amuse-
  77. ment at how I worked through the initial code for getch() and
  78. kbhit() for Unix (thanks for the help, BTW).  But the point is
  79. that, at version 8.0, even a dummy like me could do this sort
  80. of thing.
  81.  
  82. So to end this over-long posting, the question of Icon's future,
  83. I think, doesn't have so much to do with thinking through how
  84. to do things like sockets in an elegant and platform-independent
  85. fashion.  Rather, it has more to do with how to avoid doing such
  86. things - but yet of providing facilities for dummies like me to
  87. access facilities already present in our OS for doing them.
  88.  
  89. Take this posting for what, if anything, it's worth.  And feel
  90. free to flame me if I don't seem to understand what is going
  91. on.
  92.  
  93. Your friend (and a long-time, devoted Icon programmer),
  94.  
  95. Richard Goerwitz